1. Field of the Invention
This invention relates to technologies and methods for modifying, deleting, merging and otherwise processing text-based computer files on a mass scale in environments such as database management and web site management.
2. Description of the Related Art
Many companies operate large-scale computing facilities which house great amounts of data in files and database records, including inventory information, financial transaction information, customer orders, etc. Most of these systems are based upon “main frame” class computers and storage solutions, such as the S/390 computer from International Business Machines (“IBM”), and much of this information is stored in a “text” format, such as ASCII text files, Hyper Text Markup Files (“HTML”), and the like.
To manage these types of data stores, most main frame computers are equipped with various software tools, some of which are supplied with or integral to the operating system, and some of which are available separately as a “stand alone” utility function. For example, IBM's OS/390, which is the operating system run on the S/390 computer, is provided with a user interface called “Interactive System Productivity Facility” (“ISPF”), which allows the user to maintain and configure the system (e.g. file deletions, file opens, file creations).
Many tasks performed in these computing environments require creating and handling of redundant text data, which must either be entered manually, copied from libraries, or require a highly specialized program to be written explicitly for the task. For example, a web site administrator may want to perform a similar update to a block of HTML in 1200 files which comprise a company web site, such as changing all references to the company's address and telephone. The administrator can either manually change all 1200 files, write a program to make the changes, or use an operating system utility (if available) to make the changes.
Among its many features, ISPF provides a utility called the File Tailoring Function (“FTF”), which provides a means of text generation and modification on a large-scale basis (e.g. hundreds to thousand of records or files to be modified). While this addresses the redundant text management issue to some degree, FTF has some limitations to its use. A main limitation to the ISPF FTF utility is that it only accepts input in one specific database or tabular format. As a consequence of this limitation, administrators who wish to use the FTF utility must first build a plurality of tables containing the text to be modified for input to FTF, regardless of what will be generated by the FTF (generating text or HTML files, program code, database tables all requires input in a tabular form). In general, this would be too great of a task to be handled manually, so the administrator is forced to write a unique “preprocessing” program to format the input data into the requisite tabular format.
Another FTF limitation lies in the batch processing (e.g. performing the same or similar tasks on different sets of data at a single time) capabilities of the FTF utility. If the user wishes to perform several similar operations, for example, delete several files from the same directory according to some logical conditions (e.g. delete all files whose name begins with the string “abc”), the table of inputs (the file path and name) must be updated after each file is deleted to hold the name of a new file to be deleted, and then FTF must be rerun.
Therefore, batch operations can be very difficult to implement and time-consuming to execute. For more complex operations, extensive table modifications (via cut/copy/paste or query replace) and an overwhelming number of repetitive calls to FTF may be required.
To simplify this task, many users utilize JCL (Job Control Language), which manages and organizes jobs sent to the operating system, to automate the execution process. Unfortunately, this requires a unique JCL script to be written for each task, which, although resulting in an improvement on a case-by-case basis, remains time-consuming and inefficient when considered on a larger scale. For example, an administrator who wishes to merge certain records from certain databases, extract other records into separate files, and delete other files, may first open an existing JCL file which was previously created for a similar task, edit that JCL file (cut, paste, etc.), and save that JCL file under a new name for use in this operation. This is more efficient than writing new JCL for every task, but also can become cumbersome to manage (e.g. remember) the details of each old JCL file thereby increasing the possibility of errors in the processing on a wholesale basis.
This common practice is illustrated in FIG. 1 for an OS/390 and ISPF environment. Similar actions and tasks are undertaken on other computers and operating systems, wherein the terminology may differ but the concepts and actions are essentially the same. In the ISPF environment, data items are organized as members of a Partition Data Set (“PDS”). In another environment, such as a computer running a Microsoft Windows [TM] operating system, this organization may be referred to as “files” organized into “folders” or “directories”. These synonymous terminologies are well-known in the art. For the purposes of this disclosure, terminology relevant to the OS/390 and ISPF environments will be primarily used, although synonyms may be provided to enhance understandability as the problem of the present art exists in all available computing environments, not just in the OS/390 environment.
First, a user or administrator would create (11) an ISPF FTF “skeleton” (e.g. output template) which indicates to the FTF utility how the output data is to be formatted (e.g. the objective of the operation).
Next, the user would format the input data (tables, databases, files, etc.) into the requisite table format either manually, or by creating a custom JCL file (12). In some cases, a similar or close set of tables or JCL may already be available, so these may be edited using common cut-and-paste operations (13) instead of creating tables or JCL from scratch.
If custom JCL is being used to preprocess the data, it is run (14) on the data, and then the ISPF FTF utility is invoked on the tabular data. The FTF utility is also supplied with the skeleton as created earlier (11) as one of its inputs.
Then, if (16) more operations are required (e.g. similar operations with minor differences), the tabular input and/or JCL are revised (13), rerun (14), and the ISPF FTF utility is invoked again (15). This loop continues until all operations have been completed successfully on all data items to be “tailored”, at which point, the process is complete (17).
Therefore, there is a need in the art for a system and method which allows for consistent generation of text that can be tailored to a wide variety of needs, situations, and applications, whether the text be database records.